Coherency across disjoint caches in clustered environments

ABSTRACT

Disclosed herein are methods, systems, and processes to provide coherency across disjoint caches in clustered environments. It is determined whether a data object is owned by an owner node, where the owner node is one of multiple nodes of a cluster. If the owner node for the data object is identified by the determining, a request is sent to the owner node for the data object. However, if the owner node for the data object is not identified by the determining, selects a node in the cluster is selected as the owner node, and the request for the data object is sent to the owner node.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present patent application is a continuation of U.S. patentapplication Ser. No. 15/476,447, filed on Mar. 31, 2017, entitled“Coherency Across Disjoint Caches In Clustered Environments,” which isincorporated by reference herein in its entirety and for all purposes.

FIELD OF THE DISCLOSURE

The present disclosure is related to distributed storage in clusteredenvironments. In particular, this disclosure is related to providingcoherency across disjoint caches in a cluster.

DESCRIPTION OF THE RELATED ART

A cluster is a distributed computing system with several nodes that worktogether to provide processing power and shared storage resources byspreading processing load over more than one node, as well aseliminating or at least minimizing single points of failure. Therefore,applications running on multiple nodes can continue to function despitea problem with one node (or computing device) in the cluster.

Application throughput in such clustered environments can be improved bystoring data in caches maintained by nodes in the clusters. For example,requests for data can be served from a Solid State Drive (SSD)implemented as a cache by one or more nodes in a cluster (as opposed toretrieving the data from a slower backend storage device), thus reducinginput/output (I/O) latency.

Existing caching solutions have several limitations. For example, cachesimplemented in such computing environments are local (each node in acluster maintains its own cache locally). There exists no mechanism forvarious disjoint caches in a cluster to interact with each other in ameaningful manner to share data (and data access information) to avoidI/Os to slower backend storage devices. Thus, latency and throughput arenegatively affected.

SUMMARY OF THE DISCLOSURE

Disclosed herein are methods, systems, and processes to providecoherency across disjoint caches in clustered environments. One suchmethod involves determining whether a data object is owned by an ownernode, where the owner node is one of multiple nodes of a cluster. Inthis example, if the owner node for the data object is identified by thedetermining, the method sends a request to the owner node for the dataobject. However, if the owner node for the data object is not identifiedby the determining, the method selects a node in the cluster as theowner node, and sends the request for the data object to the owner node.

In one embodiment, the method instructs the owner node to cache the dataobject prior to sending the request to the owner node for the dataobject, if owner node is not identified by the determining. In thisexample, the method receives the request for the data object from anapplication, determines whether a master node maintains informationidentifying the owner node for the data object, and selects the node inthe cluster as the owner node if the master node does not maintaininformation identifying the owner node for the data object.

In another embodiment, the method determines that the owner node takes alock on the data object and the lock information is maintained by adistributed lock manager (e.g., a master node). In some embodiments,selecting the node as the owner node is based on a random selectionmethod, a circular selection method, or a cache characteristic selectionmethod.

In other embodiments, selection of the node in the cluster as the ownernode is performed by a reader node, and a subsequent request for thedata object from another reader node is serviced by the owner node byvirtue querying the master node for the lock information in thedistributed lock manager and determining that the owner node holds thelock.

In certain embodiments, the owner node, the master node, the readernode, and another reader node are part of the nodes, the owner node iscommunicatively coupled to a local storage device which is a Solid StateDrive (SSD), and the nodes, which may have SSDs, are communicativelycoupled to a shared storage device which is a Hard Disk Drive (HDD).

The foregoing is a summary and thus contains, by necessity,simplifications, generalizations and omissions of detail; consequentlythose skilled in the art will appreciate that the summary isillustrative only and is not intended to be in any limiting. Otheraspects, features, and advantages of the present disclosure, as definedsolely by the claims, will become apparent in the non-limiting detaileddescription set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings.

FIG. 1 is a block diagram 100 of a computing system for providingcoherency across caches in a clustered environment, according to oneembodiment of the present disclosure.

FIG. 2A is a block diagram 200A of a distributed storage environment,according to one embodiment of the present disclosure.

FIG. 2B is a table 200B illustrating data object ownership, according toone embodiment of the present disclosure.

FIG. 3A is a block diagram 300A that illustrates selection of an ownernode, according to one embodiment of the present disclosure.

FIG. 3B is a block diagram 300B that illustrates performing input/output(I/O) operations using an owner node, according to one embodiment of thepresent disclosure.

FIG. 4 is a flowchart 400 of a process for servicing read request froman owner node, according to one embodiment of the present disclosure.

FIG. 5 is a flowchart 500 of a process for owner node selection,according to one embodiment of the present disclosure.

FIG. 6 is a flowchart 600 of a process for determining whether an ownernode exists, according to one embodiment of the present disclosure.

FIG. 7 is a flowchart 700 of a process for owner node selection.according to one embodiment of the present disclosure.

FIG. 8 is a block diagram 800 of a computing system, illustrating how adata object ownership manager and a read request manager can beimplemented in software, according to one embodiment of the presentdisclosure.

FIG. 9 is a block diagram 900 of a networked system, illustrating howvarious devices can communicate via a network, according to oneembodiment of the present disclosure.

While the disclosure is susceptible to various modifications andalternative forms, specific embodiments of the disclosure are providedas examples in the drawings and detailed description. It should beunderstood that the drawings and detailed description are not intendedto limit the disclosure to the particular form disclosed. Instead, theintention is to cover all modifications, equivalents and alternativesfalling within the spirit and scope of the disclosure as defined by theappended claims.

DETAILED DESCRIPTION Introduction

A persistent caching solution (e.g., VxFS) improves overall throughoutof applications by caching data objects in a cache. Storing data objectsin this manner reduces input/output (I/O) latency by using a cachinglayer (e.g., high end and expensive arrays) on top of slower backendstorage devices (e.g., low end commodity storage). In this manner,persistent caching solutions can be used to reduce I/O bottleneckscreated by reading data from and writing data to backend storage devices(e.g., a Hard Disk Drive (HDD)). Servicing an application I/O from acache (e.g., a Solid State Drive (SSD)) generally improves throughput asSSD media provide lower latency than magnetic media (e.g., a HDD).

As noted, one limitation of existing persistent caching solutions, amongmany, is that caches are implemented locally. These caches do notinteract and/or communicate with each other to share data and dataaccess information. Also, there is no mechanism to exploit data residentin other caches in a cluster. What's more, cold and conflict misses mustalways be serviced from an underlying storage device. For instance, adata object maintained on a local cache implemented by a node in acluster cannot be used to service a read request generated by anothernode in the cluster. The other node has to read the data object frombackend storage, and retrieve the data object from the backend storage(e.g., over a network).

Because cache visibility in existing persistent caching solutions (e.g.,asymmetric SSD configurations) is limited to a local node thatimplements the cache, a given data object already cached in anothernode's cache cannot be accessed to service I/O operations (e.g., usinghigh speed interconnects). Therefore, unfortunately, this communicationgap between disjoint caches in clustered environments can significantlyincrease the number of I/Os to backend storage and can also result inthe under-utilization of caches.

Disclosed herein are methods, systems, and processes to providecoherency across disjoint caches in clustered environments.

Example of a Persistent Distributed Read Cache in a Cluster

FIG. 1 is a block diagram 100 of a computing system for providingcoherency across caches in a clustered environment, according to oneembodiment. The system of FIG. 1 implements a persistent distributedread cache for a cluster file system. As shown in FIG. 1, a cluster 105includes nodes 110(1)-(N). Node 110(1) is communicatively coupled to alocal storage device 150(1). In this example, local storage device150(1) is a cache and is implemented using a Solid State Drive (SSD).However, it must be noted that not all nodes in cluster 105 need to becommunicatively coupled to a local storage device, and other storagedevices other than SSDs can be used to implement caches in cluster 105.

Cluster 105 is also communicatively coupled to shared storage devices155 using network 160. In one embodiment, shared storage devices 155include one or more storage devices such as Hard Disk Drives (HDDs) thatfunction as backend storage for nodes 110(1)-(N) executing in cluster105. Shared storage devices 155 can include other types of storagedevices other than HDDs.

As shown in FIG. 1, node 110(1) includes at least an application 115(1),a file system 120(1), a lock manager 125(1), cached data information130(1), cache availability information 135(1), a data object ownershipmanager 140(1), and a read request manager 145(1). Application 115(1)can be a standalone application executing on node 110(1), or can be adistributed application executing across two or more nodes in cluster105. In one embodiment, file system 120(1) is a Cluster File System(CFS) and keeps track of files and data objects accessed by application115(1), and other applications. In another embodiment, lock manager125(1) is a Global Lock Manager (GLM) and is a distributed lockingmechanism that is used for metadata and cache coherency across multiplenodes in cluster 105. For example, lock manager 125(1) provides amechanism to ensure that all nodes have a consistent view of file system120(1), and can be used to designate exclusive ownership of certain dataobjects maintained by file system 120(1) to one or more nodes in cluster105.

Cached data information 130(1) includes information or metadata thatidentifies data objects that are cached in local storage device 150(1)by node 110(1). Cache availability information 135(1) includesinformation about a cache implemented on local storage device 150(1).For example, cache availability information 135(1) can includeinformation such as size of a cache, used cache space, free cache space,and the like. In one embodiment, when the cache of a given node isbrought online, the node broadcasts a message to other nodes in cluster105 with the node's cache availability information. This broadcast cantake place when the cache is available for sharing and also when thecache is no longer available for sharing. Cache availability informationcan be maintained in a specific bitmap per file system on multiple nodesin cluster 105 (e.g., a consistent copy of the bitmap can be maintainedon all nodes per file system). When a node leaves cluster 105, thebitmap can be updated cluster-wide as part of cluster reconfiguration.

Data object ownership manager 140(1) assigns one or more nodes incluster 105 ownership of one or more data objects. For example, if FileA maintained by file system 120(1) consists of data objects A and B,data object ownership manager 140(1) can assign or designate ownershipof data object A to node 110(2), ownership of data object B to node110(3), and the like. This “ownership” information can also bemaintained using a bitmap, and this bitmap can be shared among thevarious nodes in cluster 105. Read request manager 145(1) manages readrequests generated by application 115(1). For example, read requestmanager 145(1) can be used to identify an owner node of a given dataobject, and can be used to instruct the owner node to cache theidentified data object and service a read request for the identifieddata object.

FIG. 2A is a block diagram 200A of a distributed storage environment,according to one embodiment. As shown in FIG. 2A, nodes 110(1)-(N) eachhave a cache 205(1)-(N), respectively, and are communicatively coupledto shared storage devices 155 using network 160. However, as notedabove, each node need not have a (local) cache. For example, node 110(4)need not have a cache, but can still receive one or more data objectscached in caches 205(1) and 205(2) by nodes 110(1) and 110(2),respectively, to service a read request generated by an applicationexecuting on node 110(4) (e.g., application 115(4)), for example.

Example of Owner Node Selection

In one embodiment, a reader node is a node in cluster 105 that requests(and requires) one or more data object to service and fulfill a readrequest (e.g., generated by an application). When a reader node detectsor receives a request for a data object, the reader node accesses andqueries a master node for the data object in a distributed lock manager(e.g., provided by a master node) in cluster 105 to determine whetherthe master node has information that identifies an owner node for thedata object. In this example, the owner node is a node in cluster 105other than the reader node that “owns” (and caches) the data object. Themaster node is a node in cluster 105 other than the reader node and theowner node, and maintains a locking mechanism for the data object thatpermits the data object to be accessed from the owner node. Any node incluster 105 can a reader node, an owner node, or a master node.

The master node is part of a lightweight GLM and maintains lockinginformation that identifies locks for data objects held by various“owner” nodes in cluster 105. Once a lock for a data object is assignedto an owner node by the master node, no other node in 105 can hold thelock for that data object. Therefore, a node which is designated orselected as an owner for a data object (e.g., a particular portion of afile), uses this lightweight locking mechanism to “own” that dataobject.

As previously noted, a reader node accesses and queries a master node incluster 105 to determine whether the master node has information thatidentifies an owner node for the data object in question. If the masternode does not have (or provide) information that identifies an ownernode for the data object, the reader node selects a node in cluster 105as the owner node for that data object. In certain embodiments, thereader node can select an owner node for the data object based onvarious policies and/or methodologies. For example, the owner node canbe selected by the reader node randomly, using a Round-robin method,based on cache characteristic(s) of a given node, or based on apreference given to a local node.

For example, a reader node can select any node in cluster 105 randomlyas an owner node for a data object. The reader node can also select anode in cluster 105 in a circular manner (e.g., using a Round-robinmethodology). In addition, a node can be selected by the reader node asthe owner node based on cache characteristic(s) of a given node (e.g.,based on cache available information 135(1)). For instance, a node whichhas the largest free cache space in its cache, a node which stores thesmallest number of data objects in its cache, or a node whose cache isnot being actively utilized, and the like, can be policies that can beused by the reader node to select a given node as the owner node for thedata object.

FIG. 2B is a table 200B illustrating data object ownership, according toone embodiment. As shown in FIG. 2B, data object ownership table 210includes at least a file field 215, a data object field 220, an ownerfield 225, and a lock manager field 230. For example, File A includesdata objects 235(1), 235(2), and 235(3). Node 110(1) is selected as anowner node for data object 235(1) by a reader node, node 110(2) isselected as an owner node for data object 235(2) by a reader node, andnode 110(3) is selected as an owner node for data object 235(3) by areader node. The master node that maintains information indicating thatnode 110(1) is an owner node for data object 235(1) is node 110(4), themaster node that maintains information indicating that node 110(2) is anowner node for data object 235(2) is node 110(3), and the master nodethat maintains information indicating that node 110(3) is an owner nodefor data object 235(3) is node 110(5). Similarly, File B includes dataobjects 235(6) and 235(7). Node 110(2) is selected as an owner node fordata objects 235(6) and 235(7) by a reader node. The master nodes thatmaintains information indicating that node 110(2) is an owner node fordata objects 235(6) and 235(7) are nodes 110(1) and 110(4),respectively. In this manner, each data object of a file maintained by acluster file system can be assigned or designated an owner node, whichcan be selected by a reader node (e.g., a node requesting a data object)using one or more of the methodologies discussed above. In oneembodiment, data object ownership table 210 is a bitmap and can bemaintained by a master node, and a selected owner node. In otherembodiments, a consistent copy of data object ownership table 210 can beshared between multiple nodes in cluster 105, and can be updated (e.g.,upon a node entering or leaving cluster 105) during clusterreconfiguration.

Example of Read Request Processing

FIG. 3A is a block diagram 300A that illustrates selection of an ownernode to service read requests from disjoin caches in a cluster,according to one embodiment. As shown in FIG. 3A, a reader node 305first queries a master node 310 for an owner of the data object (e.g.,query data object owner). If no owner is found by master node 310,reader node 305 selects a node in cluster 105 as the owner node, andinstructs a selected node 315 to take ownership (of the data object).Selected node 315 accesses master node 310 to determine whether it cantake ownership of the data object (e.g., using a lightweight GLMprocedure). If selected node 315 is granted a lock of the data object,then selected node 315 is designated as an owner node 320, and readernode 305 receives a confirmation from owner node 320 and/or master node310 that the owner node selection process is successful. Once the ownernode selection process is successful, read requests for the data object(current and subsequent) can be fulfilled by owner node 320, regardlessof which reader node makes the read request.

FIG. 3B is a block diagram 300B that illustrates performing input/output(I/O) operations using an owner node, according to one embodiment.Reader node 305 detects or receives a request for a data object (e.g., aportion of a file from an application). Reader node 305 performs abitmap lookup for a range of data available in a local cache (e.g.,local storage device 150(1)), and serves the data object if the dataobject is available in the local cache of reader node 305. However, ifthe data object is not found in the local cache of reader node 305,reader node 305 queries master node 310 to identify the owner of thedata object. If the data object does not have an owner, reader node 305selects a node for ownership (e.g., owner node 320), and requests theselected node to take ownership of the data object. If the selected nodefails to take ownership of the data object, reader node 305 restarts theowner node selection process. Upon successful owner node selection,reader node 305 queries the data object at the cache of owner node 320(e.g., local storage device 150(2)) via bitmap lookup on the cache ofowner node 320. If the data object is available on the cache of ownernode 320, reader node 305 issues a Remote Direct Memory Access (RDMA)request to read the data object from local storage device 150(2) (e.g.,lookup bitmap and request available data objects in a single message).

In certain embodiments, the reader node retrieves data objects that areavailable on the owner node and then requests the remaining data objectsfrom shared storage devices. For example, when a reader node (e.g., N1)does not find an owner node by contacting a master node for the dataobject in distributed lock manager (e.g., N2), the reader node selects anode (e.g., N3) to be the owner. N3 tries to take a lock on the dataobject using distributed lock manager, and then N2 maintains informationthat N3 is holding the lock (and is hence the owner). In this example,N2 is the master node, because N2 provides the distributed lock manager.

It will be appreciated that any reader node (e.g., either N1, N2, N3 orN4) can communicate with N2 and determine that N3 is holding the lockand is hence the owner, and can then send a read request to N3. Itshould also be noted that a read request can cover multiple data objectsand the reader node can asynchronously send read requests in parallel toowner nodes (which can be different nodes) for those data objects, andreturn the data objects to the application (when responses from allowner nodes have been received).

If the request data includes data objects other than the data objectfound on local storage device 150(2), reader node 305 reads theremaining data objects (if any) from backend storage (e.g., sharedstorage devices 155). Reader node 305 then waits for the asynchronousread requests to complete before fulfilling the (original) read request.In one embodiment, reader node 305 uses local storage device 150(1)(e.g., local cache) to hold copies of data objects owned by other ownernode(s). This procedure further reduces network traffic as most of therequested data can be served from local caches. Reader node 305 can readahead data from a remote cache (e.g., from local storage device 150(2))if an application is requesting data in sequence (and if reader node 305has a full file grant). In this example, reader node 305 can alsomaintain information about the number of sequential I/Os. If the numberof sequential I/Os is more than a given threshold, reader node 305 canrequest read ahead of data object(s) from the remote cache. Thepopulation of data objects from multiple remote caches and backendstorage can be performed in parallel, which further reduces the timerequired to populate the requested data.

In one embodiment, reader node 305 determines whether a data object(e.g., data object 235(1)) is owned by an owner node (e.g., owner node320). If an owner node can be identified for the data object (e.g., byquerying a master node), reader node 305 sends a request to the ownernode for the data object. However, if an owner node for the data objectis not identified by reader node 305, reader node 305 selects a node incluster 105 as the owner node and sends the request for the data objectto the owner node. In another embodiment, reader node 305 instructsowner node 320 to cache the requested data object prior to sending therequest to owner node 320 for the data object (e.g., if a node is notidentified as an owner node by a master node and has to be selected bythe reader node). Reader node 305 receives the request for the dataobject from an application, determines whether a master node maintainsinformation identifying the owner node for the data object, and selectsa node in the cluster as the owner node if the master node does notmaintain information identifying the owner node for the data object(e.g., selected node 315). It will be appreciated that in certainembodiments, the owner node, the master node, the reader node, andanother reader node are part nodes 110(1)-(N) of cluster 105, owner node320 is communicatively coupled to local storage device 150(2) which isan SSD and the nodes (which can also have SSDs) are communicativelycoupled to shared storage devices 155 which includes one or more HDDs.

Example Processes of Owner Node Selection and Read Request Processing

FIG. 4 is a flowchart 400 of a process for servicing read request froman owner node, according to one embodiment. The process begins at 405 bydetecting a request for a data object (e.g., read request manager 145(1)detects a request for one or more data objects that are part of one ormore files). At 410, the process queries a master node (e.g., masternode 310 that provides lightweight GLM capabilities) for an owner nodeof the data object. At 415, the process determines whether the ownernode for the data object has been identified (e.g., using data objectownership manager 140(1)). If the owner node for the data object can beidentified by the master node, the process loops to 430 and sends arequest for the data object to the owner node, and at 435, determines ifthere is another data object to process. If there is another data objectto process, the process loops to 405. Otherwise, the process ends.

However, if the owner node for the data object cannot be identified bythe master node, the process, at 420, selects an owner node from nodes110(1)-(N) in cluster 105 as the owner node (e.g., a node other than themaster node and the reader node itself, for example, randomly, using aRound-robin methodology, or based on cache characteristic(s) of a givennode, as discussed above). At 425, the process confirms that the(selected) owner node (e.g., owner node 320) has cached the data object(e.g., from shared storage device) by receiving a notification fromowner node 320 that the data object has been cached and is available tobe served to fulfill the (pending) read request. At 430, the processsends a request for the data object to the owner node, and at 435,determines if there is another data object to process (e.g., required toservice the read request). If there is another data object to process,the process loops to 405. Otherwise, the process ends.

FIG. 5 is a flowchart 500 of a process for owner node selection,according to one embodiment. The process begins at 505 by receiving anowner node selection request from a reader node. At 510, the processtakes a lock for the data object from a master node (e.g., lock manager125(1) uses a lightweight GLM procedure to secure the lock). At 515, theprocess caches the data object (e.g., from shared storage devices 155).The process ends at 525 by serving subsequent read requests for the dataobject from the (current) reader node or from other reader nodes (e.g.,from local cache).

FIG. 6 is a flowchart 600 of a process for determining whether an ownernode exists, according to one embodiment. The process begins at 605 byreceiving a request for an owner node of a data object from a readernode. At 610, the process determines if an owner node exists for thedata object (e.g., based on which node has a lightweight GLM lock forthe given data object). If an owner node exists for the data object, at615, the process provides owner node identification information for thedata object to the reader node, and at 635, determines whether there isanother read request to process. If there is another read request toprocess, the process loops to 605. Otherwise, the process ends.

However, if an owner node does not exist for the data object, theprocess, at 620, receives owner node selection information from thereader node, and at 625, provides a lock to the data object to the(selected) owner node. At 630, the process updates the a bitmap with newownership information for the data object (e.g., using data objectownership manager 140(1)), and at 635, determines whether there isanother read request to process. If there is another read request toprocess, the process loops to 605. Otherwise, the process ends.

FIG. 7 is a flowchart 700 of a process for owner node selection.according to one embodiment. The process begins at 705 by determiningthat there is no owner node for a data object. The process ends at 710by selecting an owner for the data object randomly, using a Round-robinmethodology, or based on cache characteristic(s) of a given node.

Example of Write Request Processing

In one embodiment, with respect to processing write request, all cachedcopies of data across disjoint caches (e.g., caches 205(1)-(N)) areinvalidated. Writes are then performed to backend storage (e.g., sharedstorage devices 155) and the (written) data is also copied to a localcache (e.g., to cache 205(1) by node 110(1)).

In another embodiment, if a given node writes data objects, the writtendata objects are copied to backend storage (e.g., to shared storagedevices 155) and copied to the cache of the owner node (e.g., localstorage device 150(2)). In this manner, the owner node can maintain anupdated copy of the data objects, and another node in cluster 105 canrequest the data object(s) from the owner node instead of accessing thedata objects from backend storage. In this example, the owner nodeupdates the copy of the data objects by taking an exclusive PG LOCK,which invalidates other copies of the data object(s) in caches otherthan the cache of the owner node, thus eliminating stale copies of datain the cluster.

Example Computing Environment

FIG. 8 is a block diagram 800 of a computing system, illustrating how adata object ownership manager and a read request manager can beimplemented in software, according to one embodiment. Computing system800 can include a cluster 105 and nodes 110(1)-(N), and broadlyrepresents any single or multi-processor computing device or systemcapable of executing computer-readable instructions. Examples ofcomputing system 800 include, without limitation, any one or more of avariety of devices including workstations, personal computers, laptops,client-side terminals, servers, distributed computing systems, handhelddevices (e.g., personal digital assistants and mobile phones), networkappliances, storage controllers (e.g., array controllers, tape drivecontroller, or hard drive controller), and the like. In its most basicconfiguration, computing system 800 may include at least one processor855 and a memory 860. By executing the software that executes a dataobject ownership manager and/or a read request manager, computing system800 becomes a special purpose computing device that is configured toprovide coherency and data persistency across disjoint caches inclustered environments.

Processor 855 generally represents any type or form of processing unitcapable of processing data or interpreting and executing instructions.In certain embodiments, processor 855 may receive instructions from asoftware application or module. These instructions may cause processor855 to perform the functions of one or more of the embodiments describedand/or illustrated herein. For example, processor 855 may perform and/orbe a means for performing all or some of the operations describedherein. Processor 855 may also perform and/or be a means for performingany other operations, methods, or processes described and/or illustratedherein. Memory 860 generally represents any type or form of volatile ornon-volatile storage devices or mediums capable of storing data and/orother computer-readable instructions. Examples include, withoutlimitation, random access memory (RAM), read only memory (ROM), flashmemory, or any other suitable memory device. Although not required, incertain embodiments computing system 800 may include both a volatilememory unit and a non-volatile storage device. In one example, programinstructions implementing a data object ownership manager and/or a readrequest manager may be loaded into memory 860.

In certain embodiments, computing system 800 may also include one ormore components or elements in addition to processor 855 and/or memory860. For example, as illustrated in FIG. 8, computing system 800 mayinclude a memory controller 820, an Input/Output (I/O) controller 835,and a communication interface 845, each of which may be interconnectedvia a communication infrastructure 805. Communication infrastructure 805generally represents any type or form of infrastructure capable offacilitating communication between one or more components of a computingdevice. Examples of communication infrastructure 805 include, withoutlimitation, a communication bus (such as an Industry StandardArchitecture (ISA), Peripheral Component Interconnect (PCI), PCI express(PCIe), or similar bus) and a network.

Memory controller 820 generally represents any type/form of devicecapable of handling memory or data or controlling communication betweenone or more components of computing system 800. In certain embodimentsmemory controller 820 may control communication between processor 855,memory 860, and I/O controller 835 via communication infrastructure 805.In certain embodiments, memory controller 820 may perform and/or be ameans for performing, either alone or in combination with otherelements, one or more of the operations or features described and/orillustrated herein.

I/O controller 835 generally represents any type or form of modulecapable of coordinating and/or controlling the input and outputfunctions of an appliance and/or a computing device. For example, incertain embodiments I/O controller 835 may control or facilitatetransfer of data between one or more elements of computing system 800,such as processor 855, memory 860, communication interface 845, displayadapter 815, input interface 825, and storage interface 840.

Communication interface 845 broadly represents any type or form ofcommunication device or adapter capable of facilitating communicationbetween computing system 800 and one or more other devices.Communication interface 845 may facilitate communication betweencomputing system 800 and a private or public network includingadditional computing systems. Examples of communication interface 845include, without limitation, a wired network interface (such as anetwork interface card), a wireless network interface (such as awireless network interface card), a modem, and any other suitableinterface. Communication interface 845 may provide a direct connectionto a remote server via a direct link to a network, such as the Internet,and may also indirectly provide such a connection through, for example,a local area network (e.g., an Ethernet network), a personal areanetwork, a telephone or cable network, a cellular telephone connection,a satellite data connection, or any other suitable connection.

Communication interface 845 may also represent a host adapter configuredto facilitate communication between computing system 800 and one or moreadditional network or storage devices via an external bus orcommunications channel. Examples of host adapters include, SmallComputer System Interface (SCSI) host adapters, Universal Serial Bus(USB) host adapters, Institute of Electrical and Electronics Engineers(IEEE) 1394 host adapters, Serial Advanced Technology Attachment (SATA),Serial Attached SCSI (SAS), and external SATA (eSATA) host adapters,Advanced Technology Attachment (ATA) and Parallel ATA (PATA) hostadapters, Fibre Channel interface adapters, Ethernet adapters, or thelike. Communication interface 845 may also allow computing system 800 toengage in distributed or remote computing (e.g., by receiving/sendinginstructions to/from a remote device for execution).

As illustrated in FIG. 8, computing system 800 may also include at leastone display device 810 coupled to communication infrastructure 805 via adisplay adapter 815. Display device 810 generally represents any type orform of device capable of visually displaying information forwarded bydisplay adapter 815. Similarly, display adapter 815 generally representsany type or form of device configured to forward graphics, text, andother data from communication infrastructure 805 (or from a framebuffer, as known in the art) for display on display device 810.Computing system 800 may also include at least one input device 830coupled to communication infrastructure 805 via an input interface 825.Input device 830 generally represents any type or form of input devicecapable of providing input, either computer or human generated, tocomputing system 800. Examples of input device 830 include a keyboard, apointing device, a speech recognition device, or any other input device.

Computing system 800 may also include storage device 850 coupled tocommunication infrastructure 805 via a storage interface 840. Storagedevice 850 generally represents any type or form of storage devices ormediums capable of storing data and/or other computer-readableinstructions. For example, storage device 850 may include a magneticdisk drive (e.g., a so-called hard drive), a floppy disk drive, amagnetic tape drive, an optical disk drive, a flash drive, or the like.Storage interface 840 generally represents any type or form of interfaceor device for transferring and/or transmitting data between storagedevice 850, and other components of computing system 800. Storage device850 may be configured to read from and/or write to a removable storageunit configured to store computer software, data, or othercomputer-readable information. Examples of suitable removable storageunits include a floppy disk, a magnetic tape, an optical disk, a flashmemory device, or the like. Storage device 850 may also include othersimilar structures or devices for allowing computer software, data, orother computer-readable instructions to be loaded into computing system800. For example, storage device 850 may be configured to read and writesoftware, data, or other computer-readable information. Storage device850 may also be a part of computing system 800 or may be separatedevices accessed through other interface systems.

Many other devices or subsystems may be connected to computing system800. Conversely, all of the components and devices illustrated in FIG. 8need not be present to practice the embodiments described and/orillustrated herein. The devices and subsystems referenced above may alsobe interconnected in different ways from that shown in FIG. 8. Computingsystem 800 may also employ any number of software, firmware, and/orhardware configurations. For example, one or more of the embodimentsdisclosed herein may be encoded as a computer program (also referred toas computer software, software applications, computer-readableinstructions, or computer control logic) on a computer-readable storagemedium. Examples of computer-readable storage media includemagnetic-storage media (e.g., hard disk drives and floppy disks),optical-storage media (e.g., CD- or DVD-ROMs), electronic-storage media(e.g., solid-state drives and flash media), and the like. Such computerprograms can also be transferred to computing system 800 for storage inmemory via a network such as the Internet or upon a carrier medium.

The computer-readable medium containing the computer program may beloaded into computing system 800. All or a portion of the computerprogram stored on the computer-readable medium may then be stored inmemory 860, and/or various portions of storage device 850, sharedstorage devices 155, and/or local storage devices 150(1)-(N). Whenexecuted by processor 855, a computer program loaded into computingsystem 800 may cause processor 855 to perform and/or be a means forperforming the functions of one or more of the embodimentsdescribed/illustrated herein. Additionally or alternatively, one or moreof the embodiments described and/or illustrated herein may beimplemented in firmware and/or hardware. For example, computing system800 may be configured as an application specific integrated circuit(ASIC) adapted to implement one or more of the embodiments disclosedherein.

Example Networking Environment

FIG. 9 is a block diagram of a networked system, illustrating howvarious computing devices can communicate via a network, according toone embodiment. In certain embodiments, network-attached storage (NAS)devices may be configured to communicate with nodes 110(1)-(N), SSDs915(1)-(N), and/or HDDs 910(1)-(N) such as Network File System (NFS),Server Message Block (SMB), or Common Internet File System (CIFS).Network 160 generally represents any type or form of computer network orarchitecture capable of facilitating communication between nodes110(1)-(N), disjoint caches persistency system 905, and/or sharedstorage devices 155.

In certain embodiments, a communication interface, such as communicationinterface 845 in FIG. 8, may be used to provide connectivity nodes110(1)-(N), disjoint caches persistency system 905, and/or sharedstorage devices 155, and network 160. The embodiments described and/orillustrated herein are not limited to the Internet or any particularnetwork-based environment.

In some embodiments, network 160 can be a Storage Area Network (SAN). Inother embodiments, disjoint caches persistency system 905 may be part ofnodes 110(1)-(N), or may be separate. If separate, disjoint cachespersistency system 905 and nodes 110(1)-(N) may be communicativelycoupled via network 160. In one embodiment, all or a portion of one ormore of the disclosed embodiments may be encoded as a computer programand loaded onto and executed by nodes 110(1)-(N), and/or disjoint cachespersistency system 905, or any combination thereof. All or a portion ofone or more of the embodiments disclosed herein may also be encoded as acomputer program, stored on nodes 110(1)-(N), disjoint cachespersistency system 905, HDDs 910(1)-(N), and/or SSDs 915(1)-(N), anddistributed over network 160.

In some examples, all or a portion of nodes 110(1)-(N), disjoint cachespersistency system 905, HDDs 910(1)-(N), and/or SSDs 915(1)-(N) mayrepresent portions of a cloud-computing or network-based environment.Cloud-computing environments may provide various services andapplications via the Internet. These cloud-based services (e.g.,software as a service, platform as a service, infrastructure as aservice, etc.) may be accessible through a web browser or other remoteinterface.

Various functions described herein may be provided through a remotedesktop environment or any other cloud-based computing environment. Inaddition, one or more of the components described herein may transformdata, physical devices, and/or representations of physical devices fromone form to another. For example, data object ownership manager 140 andread request manager 145 may transform the behavior of nodes 110(1)-(N)in order to cause nodes 110(1)-(N) to provide coherency across disjointcaches in clustered environments. It will be appreciated that readrequests can cover multiple data objects. For example, a reader node canasynchronously send read requests in parallel to owner nodes (e.g.,different owner nodes) for data objects (owned by respectively ownernodes), and can then return (e.g., to an application) the requested dataobjects when responses from the owner nodes have been received.

Although the present disclosure has been described in connection withseveral embodiments, the disclosure is not intended to be limited to thespecific forms set forth herein. On the contrary, it is intended tocover such alternatives, modifications, and equivalents as can bereasonably included within the scope of the disclosure as defined by theappended claims.

What is claimed is:
 1. A computer-implemented method, comprising:determining whether a data object is owned by an owner node, wherein theowner node is one of a plurality of nodes of a cluster; if the ownernode for the data object is identified by the determining, sending arequest to the owner node for the data object; and if the owner node forthe data object is not identified by the determining, selecting a nodein the cluster as the owner node, and sending the request for the dataobject to the owner node.